A Grid Architecture for Comfortable Robot Control

This paper describes a research project about robot control across a computing Grid, first step toward a Grid solution for generic process control. A computational Grid can significantly improve remote robot control. It can choose at any time the most suitable machine for each task, transparently run redundant computations for critical operations, adding fault tolerance, allowing robotic system sharing among remote partners. We built a Grid spanning France and Italy and successfully controlled a navigating robot and a robotic arm. Our Grid is based on the GridRPC paradigm, the DIET environment and an IPSEC-based VPN. We turned some modules of robotic applications into Grid services. Finally we developed a high-level API, specializing the GridRPC paradigm for our purposes, and a semantics for quickly adding new Grid services. 1 Motivations and Project Overview This paper introduces a Grid architecture for comfortable and fault tolerant robot control. It is part of a larger project aiming to develop a grid solution for generic process control. Motivations. In several real situations robots must be remotely controlled. This is because we install robots where an application requires them. It can be a not computer-suitable environment, for example, for temperature constraints. Sometimes the building where the robots are is far away from that one where the computing centre is. In such a case probably the computer maintenance team is in the computing centre and it could be uncomfortable and expensive to have some computers near the robots. Simple robots, like robotic arms, just need to receive commands and sometimes to send feedback. A simple remote application can manage the situation, but a devoted machine makes sense only if the robot is continuously used. An integrated environment, like a Grid environment, can run the robotic application on the first available computer when needed. Complex robots, like navigating robots, are equipped with sensors and devices acquiring data about the surrounding environment. They send these data to a remote server running complex computations for deciding robot behavior. Navigating robot applications sometimes, but not always, need a powerful machine. A computational Grid could find a suitable machine on the fly, avoiding to devote an expensive computer to the robotic system. Finally, a computational Grid can be useful and comfortable in several other situations. It can automatically switch to an unloaded computer when the current one gets overloaded, guaranteeing some QOS to time-constrained robotic applications. Some applications are embarrassingly parallel and a Grid can offer a different server for each task. A single application execution is not fault tolerant for critical missions. A Grid can automatically run the same application on different machines, so that if one fails, another one can keep robot control. In a robotic research environment, a Grid allows remote partners to easy share a robotic system. Project Roadmap. In 2002 we started a four-step project about remote robot control across a Grid. A careful evaluation about delay, security policies, Internet uncertainty and so on [4, 6] was mandatory and the first step was about it. We worked with a self-localization application for a single navigating robot [7], using ”ssh links” and a simple client-server mechanism. We focussed on adhoc overlap techniques for amortizing the Internet communication, and at the end we achieved a reasonable slow down [8]. In the second step we built and experimented a Grid based on a secure VPN and DIET [1]. We added a navigation module, we turned both modules into Grid services, and we designed and implemented an easy-to-use and easy-to-expand robotic API [2]. In our Grid configuration the robot, a client and some computing servers were in a single site in France, while another server was in Italy. The third step is a working in progress. Using our API we quickly and easily added a lightness detection Grid service for environment checking. Then we extended the Grid with other two sites in France, each one hosting just a computing server. Finally we added a second robot (a robotic arm) and a related control module. In the fourth step we will investigate the way to adapt our software architecture to the Globus middleware. The current solution is very suitable for our applications, but Globus is an example of more generic and standard middleware. 2 Robotic Applications and Grid Testbed Hardware Resources. The physical resources on our Grid are two robots, some PCs at Metz Supelec campus, two PCs in two different sites in Metz and a PC at Salerno University, see figure 1. Our robots are an autonomous navigating Koala, with several onboard devices, and a robotic arm. Both are connected to external servers through serial links. Each server is a devoted PC controlling basic robot behaviors. All robotic applications are clients of these servers. Grid Environment. We chose the DIET [1] (Distributed Interactive Engineering Toolbox) Grid environment. It supports synchronous and asynchronous PC X1 PC QX1 PC QX2 computing servers PC robot server serial link